Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@cmd/main.go`:
- Line 272: Remove the duplicate declaration of the variable cloudMetadata (the
earlier declaration already exists in the same block), so keep the original
declaration and delete the second one found in cmd/main.go; ensure all uses
reference the existing cloudMetadata variable and do not re-declare it (look for
any remaining "var cloudMetadata" occurrences and eliminate the redundant one).

In `@pkg/objectcache/networkneighborhoodcache/networkneighborhoodcache.go`:
- Around line 208-213: The code currently skips refreshing a named user-defined
network by returning early in the periodic sync when
workloadHasUserDefinedNetwork(workloadID) is true, making user-defined NNs
effectively write-once; change the logic so that addContainer still prefers
sharedData.UserDefinedNetwork on initial creation but the periodic refresh/Sync
routine (the function that calls GetNetworkNeighborhood and updates
workloadIDToProfileState) must always attempt to refresh the named network
object and retry transient failures rather than skipping updates entirely when
workloadHasUserDefinedNetwork(workloadID) is true; locate calls to
GetNetworkNeighborhood, the addContainer path, and the periodic sync code that
uses workloadHasUserDefinedNetwork and modify the sync path to fetch/update the
cached named NN (and retry on transient errors) while preserving the
initial-preference behavior in addContainer.

In `@tests/resources/known-application-profile-wildcards.yaml`:
- Around line 12-16: Add the same required metadata.annotations used to mark
user-defined profiles to this ApplicationProfile so it is detected as a
user-defined profile; update the metadata of the ApplicationProfile with name
"fusioncore-profile-wildcards" to include the same annotations present in
known-application-profile.yaml (i.e., add the user-defined profile annotation
keys/values under metadata.annotations so the resource is recognized by the
user-defined profile detection logic).

In `@tests/resources/known-application-profile.yaml`:
- Around line 13-17: The ApplicationProfile manifest for metadata.name
"fusioncore-profile" is missing the user-defined profile annotations; add an
annotations map under metadata with keys kubescape.io/managed-by: User,
kubescape.io/status: completed and kubescape.io/completion: complete so the
ApplicationProfile resource is recognized as a user-defined, completed profile
(update the metadata block in the ApplicationProfile declaration).

In `@tests/resources/nginx-user-defined-deployment.yaml`:
- Around line 1-22: The file name is misleading: the manifest creates a
Deployment named "curl-28" with container name "curl" and labels
kubescape.io/user-defined-network: curl-nn and
kubescape.io/user-defined-profile: curl-ap, so rename the file to match the
content (e.g., curl-user-defined-deployment.yaml) and update any references in
tests or manifests that import the old filename; alternatively, if nginx is
intended, replace the image and container name in the Deployment (metadata.name
"curl-28", spec.template.spec.containers[0].name "curl", and image) to an nginx
image to make filename accurate.

In `@tests/resources/run-test-28.sh`:
- Around line 73-81: The wait loop can exit without AP reaching "completed" and
later loose alert checks allow false positives; after the loop check AP_STATUS
and fail fast (exit non-zero) if it is not "completed", and replace loose alert
count checks with explicit assertions: validate the specific ApplicationProfile
identity/annotation (use the same kubectl jsonpath that sets AP_STATUS) and
assert the expected alert name/type (not just count > 0) by querying the alert
resource (e.g., the variable used for alert count) and matching the expected
alert fields; update both the AP wait block (AP_STATUS/NS/kubectl get
applicationprofiles) and the later alert-check section (lines around 97-113)
accordingly so the script aborts on timeout and only passes when the exact
profile and alert are present.

In `@tests/scripts/local-ci.sh`:
- Around line 178-187: The current --test-only branch (guarded by TEST_ONLY)
calls start_port_forwards and then runs run_tests in a loop but stops on the
first failing run_tests and/or only preserves the last test's exit status, so
failures earlier in the list are lost and print_logs may not be reached; change
the loop to always run every requested test in TESTS (or the single run when
TESTS is empty), collect/accumulate a failure flag or an aggregate exit code
(e.g., keep a variable like overall_status=0 and set overall_status=1 if any
run_tests returns non-zero), do not exit early on a failing run, ensure
print_logs is always invoked, and exit with overall_status at the end; apply the
same pattern to the analogous block around lines 203-210.

---

Nitpick comments:
In `@tests/resources/known-network-neighborhood.yaml`:
- Around line 18-23: The metadata name "fusioncore-network" is missing the
required "ug-" prefix used by Kubescape's UserNetworkNeighborhoodPrefix and thus
won't be recognized by isUserManagedNN; rename the resource from
"fusioncore-network" to "ug-fusioncore-network" (or update the name wherever
referenced by kubescape.io/user-defined-network label) and ensure the
kubescape.io/managed-by: User annotation remains, so the isUserManagedNN
detection and any lookups by the kubescape.io/user-defined-network pod label
will consistently identify this as a user-managed NetworkNeighborhood.

In `@tests/resources/test-28-iterate.sh`:
- Around line 217-219: The jq pipeline on the ALERTS variable can fail or mask
errors; before running echo "$ALERTS" | jq ..., validate ALERTS is a valid JSON
array (e.g., use jq -e to test type=="array" or parse-then-check) and only run
the jq formatting when that check passes; otherwise print a clear "no alerts" or
skip formatting. Update the logic around the ALERTS variable and the jq
invocation (the echo "$ALERTS" | jq -r '.[] | ...' block) to perform this
validation and avoid silently swallowing parse errors with || true.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@tests/component_test.go`:
- Around line 1681-1690: The hasAlert helper (hasAlert(alerts
[]testutils.Alert)) is too coarse for R0002 wildcard subtests because it only
matches rule_name, comm and container_name; update the test to either (A) filter
alerts by the actual accessed path exposed on the alert (e.g., check
alert.Labels["path"] or alert.Annotations["path"] together with
ruleName/comm/container_name inside hasAlert) so each subtest asserts the
specific opened file, or (B) seed every fixture with the same baseline opens
(the startup files such as /etc/ld.so.cache) before asserting wildcard behavior
so unrelated startup opens don’t affect the boolean result; modify the hasAlert
usage and the fixtures accordingly to ensure each subtest validates the exact
path matcher rather than collapsing to a single boolean.

In `@tests/resources/curl-user-network-deployment.yaml`:
- Around line 3-6: The deployment's metadata.name "curl-fusioncore-deployment"
collides with the one in the other manifest; update the metadata.name in this
manifest from "curl-fusioncore-deployment" to "curl-user-network-deployment" so
it matches the filename and avoids overwriting the other Deployment when applied
(verify you only change the metadata.name field and leave the app label
"curl-fusioncore-28-1" unchanged).

In `@tests/resources/known-application-profile.yaml`:
- Around line 15-17: The metadata block for the ApplicationProfile
"fusioncore-profile" is missing the annotations used by
Test_28_UserDefinedNetworkNeighborhood and known-network-neighborhood.yaml;
update the metadata for the resource named fusioncore-profile to include an
annotations section with keys kubescape.io/managed-by: User,
kubescape.io/status: completed, and kubescape.io/completion: complete (insert
the annotations block immediately after namespace in the metadata for the
ApplicationProfile manifest so the node-agent will recognize this user-defined
profile).

In `@tests/resources/known-network-neighborhood.yaml`:
- Around line 31-33: The YAML uses spec.matchLabels but the API expects
spec.labelSelector.matchLabels; change the spec block to nest matchLabels under
labelSelector so it matches v1beta1.NetworkNeighborhoodSpec (i.e., use
labelSelector: with MatchLabels like in metav1.LabelSelector) ensuring the field
name matches the LabelSelector structure used by the code that constructs
v1beta1.NetworkNeighborhoodSpec.

In `@tests/resources/nginx-both-user-defined-deployment.yaml`:
- Around line 3-6: Deployment name collision: change the metadata.name value
currently set to "nginx-fusioncore-deployment" in
nginx-both-user-defined-deployment.yaml to a unique, filename-matching name such
as "nginx-both-user-defined-deployment"; update any cross-resource references
(e.g., selectors, Service targetNames, tests or manifests that expect the old
name) to use the new name so labels/selectors remain consistent (check
metadata.name and any occurrences of "nginx-fusioncore-deployment").

In `@tests/resources/nginx-known-network-deployment.yaml`:
- Around line 3-6: The deployment in
tests/resources/nginx-known-network-deployment.yaml uses metadata.name:
nginx-fusioncore-deployment which collides with the same name in
tests/resources/nginx-user-network-deployment.yaml and causes one apply to
overwrite the other; fix by renaming the deployment in
nginx-known-network-deployment.yaml (change the metadata.name value, e.g., to
nginx-known-network-deployment) so the "known-network" and "user-network"
manifests have distinct names and won't clobber each other when applied in the
same namespace.

In `@tests/resources/nginx-user-network-deployment.yaml`:
- Around line 3-6: The deployment's metadata.name currently uses
"nginx-fusioncore-deployment" which collides with another manifest; rename
metadata.name to "nginx-user-network-deployment" in this file (update the value
for metadata.name) and verify any related selectors or references (e.g.,
labels/selectors) still match the new name so resources remain consistent.

---

Duplicate comments:
In `@pkg/objectcache/networkneighborhoodcache/networkneighborhoodcache.go`:
- Around line 208-213: The loop currently skips user-defined
NetworkNeighborhoods via the continue in the
nnc.workloadHasUserDefinedNetwork(workloadID) branch, causing write-once
behavior and stale workloadIDToProfileState; remove the early continue and
instead, when nnc.workloadHasUserDefinedNetwork(workloadID) is true, call
nnc.GetNetworkNeighborhood(nameOrID) to refresh/read the authoritative
user-defined NN and use that result to update workloadIDToProfileState (avoiding
overwriting it with the auto-learned object), and only skip applying
auto-learned values if the fetched user-defined NN exists; ensure the check
happens before assigning the auto-learned NN into workloadIDToProfileState so
state stays consistent with the user-defined cache.